hiya! thanks - would some of these would be better as 'property' types, rather than init arguments. that way people can adjust the factors depending on use cases?

I'd also thought of exposing them as properties though what I've seen in practice is that attempting to modify values of some of these, say rssi, after using the radio can cause an indefinite hang. That behavior exists when using the current implementation's rssi property. At the moment, I am unsure of how to fix this for rssi and so was hesitant to add similar complications with more properties that can be changed immediately after instantiation but not after using the radio to send/receive. I sure like the idea though.

We could go ahead and move these input parameters to each be a property, if you think that would make for a better api... and then hope we can come back to figure out how to avoid the hang I described on the rssi property (and these new ones)?

i think lets do properties, at worst you can just set them before you begin the radio, and if we fix the bug you'll be able to adjust them whenever!

Cool -- I'll make the change and then update my code that uses it to test.

Apologies, earlier I said I'd modified rssi via its property but that was incorrect -- I was messing with frequency_mhz instead.

The changes to expose as property appear to be working happily with my existing (now updated) code.

Playing around in the interactive shell, it also appears to do what I hoped. Here, rfm9x = adafruit_rfm9x.RFM9x(...):

>>> rfm9x.coding_rate
5
>>> rfm9x.coding_rate = 7
>>> rfm9x.coding_rate
7
>>> rfm9x.coding_rate = 200  # Exceeds max allowed
>>> rfm9x.coding_rate
8
>>> rfm9x.coding_rate = -1  # Also outside allowed
>>> rfm9x.coding_rate
5
>>> rfm9x.signal_bandwidth
250000
>>> rfm9x.signal_bandwidth = 10000  # Does not match a supported value
>>> rfm9x.signal_bandwidth
10400
>>> rfm9x.signal_bandwidth = 10**6  # Exceeds max allowed
>>> rfm9x.signal_bandwidth
500000
>>> rfm9x.signal_bandwidth = -1  # Also outside allowed
>>> rfm9x.signal_bandwidth
7800
>>> rfm9x.spreading_factor
7
>>> rfm9x.spreading_factor = 11
>>> rfm9x.spreading_factor
11
>>> rfm9x.spreading_factor = -1  # Outside allowed
>>> rfm9x.spreading_factor
6
>>> rfm9x.spreading_factor = 100  # Outside allowed
>>> rfm9x.spreading_factor
12

Likewise, enable_crc appears to behave itself:

>>> rfm9x.enable_crc
False
>>> rfm9x.enable_crc = True
>>> rfm9x.enable_crc
True
>>> rfm9x.enable_crc = 0
>>> rfm9x.enable_crc
False
>>> rfm9x.enable_crc = 42
>>> rfm9x.enable_crc
True

I have yet to experiment with which settings can be safely altered after the radio has been used. The above was all done before transmitting anything. Hopefully the radio just needs to be put back into an appropriate mode to permit changing tx_power or frequency_mhz, etc. later.

i'm diggin' it!
@jerryneedell @brentru y'all use this library the most, wanna look?

Looks great. I will run some tests with it tomorrow.

thanks! @brentru check this still works with your examples you've done for the RFM9x?

@ladyada Missed this tag - I'll test this against the RFM9x Bonnet Code, examples I've written for learn, and CircuitPython_TinyLoRa first-thing tomorrow when I have access to that hardware and review.